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PRIMARY ACCESS CONTROL IN LARGE-SCALE 
TIME-SHARED DECISION SYSTEMS* 



Abstract 

The computer differs from other tools in that it presently 
•does not provide its users with a working environment transparent 
to their desires; in particular, current computer systems do not 
support adequate mechanisms for controlled sharing of sensitive 
information. 

Four primary dimensions of the access control problem are 
identified. They are: 1) the physical level at which to apply 
control; 2) the fineness of distinction applied to the term "ac- 
cess", 3) the meaning of the term "user identification", and 4) the 
degree of sophistication employed in automatically assigning restric- 
tions to new data files . 

Within the context of MacAIMS, the Project MAC Advanced Inter- 
active Management System, the design of an access control system is 
presented which takes positions along these four dimensions appro- 
priate for controlling access in a Management Decision System. Sup- 
port is provided for constraints specified as general logical restric- 
tions based on 1) the characteristics of the entity requesting access, 
2) the content of the sensitive data item, 3) the context in which the 
sensitive item appears, 4) proper completion of an interactive proce- 
dure, and 5) combinations of any of these. The access levels which 
may be specified are based on the logical (not the physical) nature 
of the interaction which the user requests . 

The system presented here is an interim system in that it does 
not solve all of the access control problems of MacAIMS . Among the 
unsolved problems is the problem of Truth — in a data management 
system which provides a powerful set of operators, it is easy to 
create false information in very subtle ways. Another problem is 
that of conflicts of privacy. Solutions to these problems must be 
found before the access control scheme will be complete. 



*This report reproduces a thesis of the same title submitted to the 
Alfred P. Sloan School of Management, Massachusetts Institute of 
Technology, in partial fulfillment of the requirements for the degree 
of Master of Science in Management, May 1971. 
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1. INTRODUCTION 



1.1. Privacy 

Consider for a moment the stone-age axe. Like all 
the tools which man designed both earlier and later In his 
history/ the axe serves as an amplifier of his abilities 
in this case, an amplifier of his ability to strike. 
Perhaps the second most important characteristic of the axe 
is that it is indifferent with regard to what it strikes; 
it may be used equally well on either a log or another man's 
head. The axe provides a working environment which Is 
amoral by itself, but which possesses the ability to reflect 
the morals of Its user. 

Like the axe, the computer is a tool: it 
amplifies man's ability to process and disseminate 
information. Computers are potentially more dangerous than 
axes by virtue of the magnitude of their amplification, but 
this difference is not basic. It is the second referent 
which distinguishes the computer from the axe In an 
essential way — in spite of the fact that considerable 
progress has been made in recent years, the environment 
provided by most present-day computer facilities lacks the 
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ability to adequately mirror wishes of the users. It is to 
a portion of this problem that the present work Is 
addressed. 

There is today no widespread publ Ic agreement 
regarding what the issues surrounding the privacy problem 
really are. In the absence of such a concensus, imposing a 
specific set of standards upon a computer system (if such an 
imposition were possible), would be almost as bad as no 
control at all. What is needed instead is to devise a 
system which is transparent to the wishes of the users 
their desires to control the flow of information should be 
exactly expressible within its environment. 

At the outset it is useful to consider briefly a 
few of the more important social issues which are now in the 
public eye. These issues have been discussed elsewhere in 
greater detail; the bibliography contains a list of some of 
the better works. 

It is probably safe to say that everyone has an 

intuitive idea of the meaning of the word "privacy"; it is 

probably also safe to say that most of those intuitions are 

over-simplistic. At least one definition of privacy has 

been suggested which emphasizes many Important aspects of 

the problem: in Privacy and Freedom - Professor Alan Westin 

has said 

"Privacy Is the claim of individuals, groups, or 
Institutions to determine for themselves when, how, and 
to what extent information about them is communicated 
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to others The individual's desire for privacy is 

never absolute, since participation in society is an 
equally powerful desire. Thus each individual is 
continually engaged in a personal adjustment 
process... in the face of pressures from the curiosity 
of others and from the processes of surveillance that 
every society sets in order to enforce its social 
norms . " 

Thus the privacy decision is the choice of an individual in 
trading off his desire to be an Individual against his 
desire to participate in society. 

From the individual's viewpoint, Dr. Westln 
identifies four primary (and essential) functions of 
privacy: it 1) provides personal autonomy, 2) gives 
opportunity for emotional release, 3) allows self-evaluation 
and Introspection, and k) permits the protected and 
privileged transfer of information. As the book's title 
indicates, these functions are very closely related to the 
concept of freedom. But the need for privacy goes even 
beyond such logical considerations — Dr. Westin suggests 
that privacy may be as much a biological necessity for man 
as It is for other animals. (31) 

The concept of norm-enforcement is inherent in the 
definition of "society". In order to enforce norms, a 
society establishes a variety of Institutions which watch 
over individuals and monitor their behavior; thus cumulative 
social pressure places constraints on each citizen's privacy 
decision. Clearly such norm-enforcement is essential to the 
preservation of civilization — we cannot, for example, 
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choose to drive at excessive speeds or to burn down our 
neighbor's house in the name of privacy. In order to 
accomplish such enforcement/ collection and processing of 
considerable amounts of information about citizens is 
necessary. A logical framework for viewing the reasons for 
this collection is discussed in (32). 

Perhaps the most important issue of the privacy 
problem, then, is the tradeoff of the individual's needs 
against the society's needs. Unanswered questions include 
the exact costs associated with that tradeoff and the 
identity of the party (or parties) who should make the final 
dec is ion . 

Another extremely important issue, and one which 
has received almost no attention to date, is that of 
conflicts of privacy. Most, if not all, data which are of 
interest are the joint property of at least two parties 
the person who originated the information, and the person 
whom the data concern. Moreover, much Information may be 
the joint property of considerably more than two parties. 
In many cases the privacy rights of these parties conflict. 
For example, a physician would not wish a patient to see his 
own medical record if that record showed he was a hopeless 
hypochondriac. A complete solution to the privacy problem 
must include mechanisms for the resolution of such 
conf 1 icts. 
1.2. The Computer and Privacy 
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The essence of the solution to the privacy 
problem, then, is providing the ability to control the flow 
of information which is in some way "sensitive". Thus the 
problem exists in all its complexity whether or not there is 
a computer at some point in the transfer process. When a 
computer system is involved, It must be so engineered that 
the ability to control the transfer of information is not 
lost. The present work is concerned with designing 
mechanisms to provide that ability. 

Most of the progress which has been made to date 
in computerized access control has been in the realm of 
time-shared systems. The motivation behind these advances, 
unfortunately, has in general been to give systems 
programmers the ability to test and debug programs without 
accidentally destroying the work of other programmers; It 
has been to prevent the destruction of Information, not to 
control the transfer of that information. The ability to 
protect privacy in the more general sense has been only a 
by-product of these efforts. That the by-products have been 
Insufficient is clear -- In the IBM System 360, for example, 
hardware read-protect is not provided as standard equipment; 
It Is possible to prevent someone from writing over your 
information, but not to prevent him from reading It. (18) 

A few systems, however, have attempted to provide 
more sophisticated access control procedures. In Multics 
the Multiplexed Information and Computing Service, (2, 5, 
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12, 20, 27) it is possible to specify on a user-by-user 
basis the permissible levels of access to each segment in 
the system. But even the Multics access control environment 
is not sufficiently general to provide convenient control of 
access to information at the logical level. 

From a more general viewpoint, the primary 
decisions for an access control design scheme can be taken 
as choices of positions along four dimensions: 

1) The physical level at which to apply access 
control . 

2) The fineness of distinction applied to the term 
"access". 

3) The meaning of the term "user Identification". 

k) The degree of sophistication employed In 
assigning restrictions to new data files. 

One might, for example, want to associate access control 
information at the work space level, at the file level, at 
the record level, at the field level, or at the level of 
individual data items. Similarly, "access" might be divided 
in half — i.e., "yes" or "no" — or It might be more finely 
divided to distinguish between "read", "write", etc. Along 
the third dimension, one might use only the user's name; at 
a slightly more sophisticated level, one might employ both 
name and password; and so on. Lastly, an access control 
system might assign null access (or full access) to everyone 
for each new file. At the opposite extreme, it might be 
able to discover the nature of the sensitivity of data in a 
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new file by knowing the access characteristics of the 
inputs. The choice of positions along these dimensions 
determines the power and abilities of the access control 
scheme. 

This work approaches the problem of access control 

from the general viewpoint within the framework of MacAIMS 

(the Project Mac. Advanced Interactive Management System) on 

Multics. (Note: the remainder of the thesis assumes a basic 

familiarity with the Multics system.) MacAIMS incorporates 

a relational approach to data management using set theory 

operators for manipulation of relations. A method for 

controlling access to information is presented which/ 

although heuristic in nature, Is more general than any 

access control scheme in common use today. For each of the 

four dimensions of access control, a position has been 

chosen which appears to provide the appropriate levels of 

power and flexibility for our needs, or else represents the 

limits of our knowledge. Experience with using the system 

will allow us to determine for each dimension whether our 

level of distinction is too coarse or too fine, and 

adjustments can be made accordingly. It is not claimed that 

the controls presented here solve all the access problems of 

MacAIMS; indeed, several classes of problems are presented 

which they cannot solve. What is claimed, however, is a 

reasonable first cut at the solution to the access control 

problem in a large scale, set-theoretic data management 
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system, and one which should be readily extendable to 
handling of those problems which we already know about, and 
those of which we are unaware. 
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2. CHARACTERISTICS OF ACCESS CONTROL SYSTEMS 



This section considers briefly the range of issues 
involved in a complete access control system for a 
multi-access computer facility and defines the scope of the 
present work. 

2.1. Jhs. Range ol Issues 

A large number of people have presented overviews 
of the access control problem; the bibliography provides a 
list of some of those works. In considering such an 
overview, a useful framework to follow Is the physical 
structure of the system. 

At the outermost level, there Is the problem of 
identifying the user at the terminal. A variety of methods 
for Identification, including passwords, keys, cards, 
voice-prints, signature recognition, and so on have been 
proposed, but most current writers fall to notice that the 
output of any Identification procedure is translated to a 
bit-string which is passed to the computer for evaluation. 
Any scheme in which that bit string Is constant over time is 
doomed to failure, since the user's password may be had 
simply by taking the trouble to tap his data line. A more 
successful alternative is the procedural password, in which 
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the user responds at each login with the answer to a 
manipulation performed on a (different) string of random 
digits supplied by the computer. Thus the password is 
different at each login. 

On the remaining issues the literature is more 
accurate. Among the problems discussed are tapping of data 
lines, physical security of the computer facility, residual 
data in core and on discs and tapes, audit trails, privacy 
encoding, program validation, and so on. 

The technology of sharing in general Is not at all 
understood by many, but is understood well by a few. The 
interested reader is referred to (7, 8, 19). 
2.2. Scope o_f XhS. Present Work 

Of all these issues, perhaps the most critical 
occur at the point where information is released from a 
file. The design decisions along the four dimensions of 
access control determine the behavior of the system at this 
point, and if those decisions are poorly made, no "amount of 
work in any other area will make the facility secure. It is 
for this reason that these decisions are termed "primary", 
and it is at this point alone that this thesis concentrates. 
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3. CURRENT ACCESS CONTROL SYSTEMS 

The literature concerning what one ought to do 
about access control is supplemented by a much smaller 
literature about what has been done. The relative 
importance of access control issues in the past is perhaps 
best illustrated by the fact that the System 360 Principles 
of Operation devotes roughly one-half page to the issue of 
protection. (18) 

This section surveys some access control schemes 
currently in use, and points out their shortcomings. 
3.1. Common Systems 

IBM's most significant efforts to provide access 
control are perhaps three: In the CP67/CMS System, files 
may be released to (all) other users in one of four modes: 
read only/ read/write/ read only and erase after one read, 
and read/write and erase after one read. However, the 
manual notes that all modes may not be implemented. (3). At 
about this same level of sophistication are the access 
specifications for the APL language; the owner of data may 
specify a password (which is the same for all users) to 
control access to a work space. (9) Somewhat better is the 
TSS/360 System, which allows specification of access 
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restrictions on a user-by-user basis with modes read/ 
read/write, unlimited, and restricts. (26) 

In the later versions of the PDP-10 monitor. 
Digital Equipment Corporation supplies a rudimentary access 
control system. The term "user" is separated into three 
categories: 1) the file owner, 2) persons on the same 
project as the owner, and 3) everyone else. Access to a 
file may be restricted for each of these three groups by 
read protection, write protection, and protection 
protection, where the last category implies the capability 
to change access control information. In addition, it Is 
possible to name files such that the monitor knows they are 
procedures. This feature may be used to enforce "execute" 
access mode. (21) 

M.l.T.'s CTSS supports a file system which is 
organized as a tree structure, and provides for sharing of 
files through links between branches of the tree. Access 
modes are essentially read, write, protected, and any 
combination thereof, and may be assigned at the time the 
link is established on a user-by-user basis. (k) 
3.2. Other Systems 

All of the systems listed above provide 
more-or-less sophisticated access control at the file level. 
Several other systems have been proposed (and In some cases, 
implemented) which protect data at a lower level. 

The TERPS system (24) allows protection at the 
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record level within files by associating a descriptor with 
each file which contains a security code for the fields. 
However, the term "access" seems to be divided only into 
"yes" or "no". Restrictions may be based on terminal 
location/ password, and security level. 

Hsiao (17) has proposed a somewhat similar system, 
although it is not clear whether implementation is past the 
pilot project stage. He distinguishes between the system 
manager, the owner of a file, and other users, and allows 
protection of Individual records within files. 

Hoffman (16) has developed a system which is 
considerably more powerful than any of these. In his 
scheme, all accesses to a data base take place through an 
intermediary program (which may be different for each user) 
called a formulary . The owner of a file supplies these 
formularies. The use of a procedure instead of table 
lookups to control access allows his scheme to be much more 
clever in assigning access privileges. 

3.3. limitations 

The limitations of these systems should be 
obvious. Several of them provide control at a physical 
level too high to be of much use. Protection at the file 
level requires that every data item in a file have exactly 
the same sensitivity; at a minimum this restriction 
requires breaking up a logical data base into a number of 
physical data bases. In non-military situations/ where 
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neither users nor information are structured as strictly 
ordered hierarchies, such a division is frequently 
imposs ibl e . 

Moreover, the term "access" is not finely 
subdivided. At best, only physical actions are 
distinguished (i.e., read y_s_. write); at worst the term is 
divided in half. Constraints cannot be based on the logical 
actions which the user wishes to perform. One cannot 
specify, for example, that a user may only extract means and 
med ians. 

In several of the systems, it is not even possible 
to make restrictions based on the user's Identity. DEC does 
not allow one to specify that "Smith can see anything in my 
files" within the context of its standard access control 
mechanisms, although such a specification might be 
implemented by special programming and the "execute only" 
mode. 

Only Hoffman's scheme does not suffer from any of 
these complaints. The idea of using procedures, though 
simple, is very powerful. Unfortunately, the job of 
supplying the formularies is left to the originator of 
sensitive data; such a task might be quite formidable. 
Moreover, there seems to be no provision for protecting the 
user of sensitive information (who might have some sensitive 
data of his own) from the effects of the formularies he 
uses. 
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In addition, none of the schemes mentioned so far 
provide the user with any more than minimal aid along the 
last primary dimension of access control: he must specify 
one-by-one the access rights to any new files in the system. 
3.U. Mul tics 

The Multics system provides a much better (though 
still insufficient) access control system. Like CTSS, the 
Multics file system is a tree structure; tt contains both 
directory branches, which contain only pointers to inferior 
branches, and non-directory branches, which are data 
segments, procedure segments, and so forth. Unlike CTSS, 
however, access control in Multics Is associated with 
branches of the tree, not with links; a user's access 
rights are evaluated each time a segment Is made known to 
him. 

Permissible access modes are read, write, execute, 
append, and combinations thereof, and may be assigned on the 
basis of users and projects. The access modes imply the 
obvious intent for non-directory branches; for directory 
branches the meaning is somewhat different. (20) Access 
Control Lists (ACL's) associated with each branch contain 
the necessary access control data. 

In addition to the file system structure, Multics 
provides a ring structure for protection which is 
essentially a generalization of the common "user" 
state/"supervisor" state idea. The mechanisms provided are 
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similar to those described by Dennis and Van Home (7); 
some of the limitations of the rings are described in (11). 
For our purposes, the important characteristic of the ring 
mechanism is that it allows one to specify that his data may 
be accessed only via a program of his own choosing. Any 
attempt to access data from an insufficiently privileged 
ring must take place through a gate into the more privileged 
ring. It is this mechanism which allows MacAIMS to help 
protect data for Its users. 

Multics also provides some aid in assigning access 
to new segments. The user may specify for each directory a 
Common Access Control List, which contains default access 
assignments for segments in the directory. In addition, 
certain conventions are followed In assigning access to new 
segments created by various compilers and other routines, 
based on the type of segment created; thus object code 
segments are assigned read/execute access. 

From MacAIMS's viewpoint, the most important 

limitation of the Multics access control scheme is that its 

permissible access capabilities, like those of the other 

systems mentioned, are not sufficiently general for powerful 

access control. For example, a perfectly reasonable 

restriction to place on the <Name, Salary> set might be 

"Smith Is allowed to extract statistical data on salary 
distributions, but not to see individual's names and 
salaries." 



3. Current Access Control Page 23 

Such a restriction is not expressible in the standard 
Multics scheme, though it could be implemented by special 
programming via the ring structure. Thus the term "read" 
does not discriminate finely enough. It is necessary to 
subdivide this capability. Like Hoffman's scheme, simply 
giving the user the ability to write his own access programs 
is not very much help. 

Moreover, Multics controls access only at the 
file level, and therefore has the inherent limitations 
common to such schemes. 
3.5. The ADEPT-50 : automatic classification of new f_ll£S. 

In addition, the Multics rules for assigning 
access to new files are insufficient. A more sophisticated 
scheme for handling new files is presented by Weissman (29). 
He views a new file as being constructed by operations which 
combine information from existing input files, each of which 
has been assigned a level of classification. The essence of 
his solution is to assign the new file the maximum 
classification level (minimum access privileges) of the 
inputs. In addition, subsequent operations on the file may 
lower the user's access privileges. 

Such a scheme is perhaps adequate in the military 
environment; in the non-military world it is insufficient. 
For example, suppose that the set <Name, Group, Salary> 
exists, that it contains information for all people 
associated with Project Mac, and that the <Salary> field is 
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considered sensitive. Suppose further that a user Is 
authorized to print salaries of people at Mac who are also 
associated with the School of Management/ but is not 
authorized to print anyone else's salary. He would not have 
access to print the entire <Name/ Group, Salary> set/ but he 
should be able to derive (in our system/ via set operations) 
a set which contains only Management personnel/ and then be 
allowed to see the results. Thus it must be possible to 
obtain a set to which the access is greater than the access 
to the Input from which it was derived. 

Both the standard Multics scheme and the ADEPT-50 
scheme are therefore Inadequate for our purposes. Before 
presenting a design which corrects some of these problems/ 
it is necessary to describe briefly the structure of 
MacAIMS. 



Page 25 



it. MADAM: 
SET-THEORETIC RELATIONAL APPROACH TO DATA MANAGEMENT 



This section provides an overview of the MacAims 
Data Management System. For a more complete introduction to 
relational data management and MacAIMS, and a detailed 
description of MADAM / the interested reader is referred to 
(13, Ik, 25). 
U.l. Description of MADAM 

MADAM operates under the assumption that any 
information which is to be stored or manipulated by the 
system consists of sets of Data Elements (DE's) and of sets 
of relations among those data elements. The DE's themselves 
are stored in Data Element Sets (DES's), and the relations 
in Relational Data Sets (RDS's). The primitives of set 
theory are the operators used for manipulating RDS's. 

Suppose that there exist DES's DES1, DES2, DES3, 
..., DESn. The RDS whtch expresses relations among elements 
of these DES's will contain n-tuples (tuples of order n_), 
each of which has as its first entry a DE from DES1, as Its 
second entry a DE from DES2, etc. The first tuple in the 
RDS will contain the names of the sets DES1, DES2, and so 
on, and is called the Relation Descriptor (RD). Thus, for 
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example, there might be two DES's: 

Name 

Jones 

Smith 

HI 1 phenhauser 



and 



Office 

505 
806 
301 



The entries "Jones", "Smith", ... "505", etc. are the DE's. 
The RDS which expresses the relations might then be: 

Name office 

Jones 505 

Smith 806 

HI 1 phenhauser 301 

Here, <Name, 0fflce> is the RD, and the 2-tuples of the RDS 
are <Jones, 505>, <SmIth, 806>, and <H1 1 phenhauser, 301>. 
In addition, the columns of the RDS are referred to as 
fields : this RDS has two fields, and their fieldnames are 
"Name", and "Office". The information In this set Is the 
fact that Jones's office Is 505, that Smith's office Is 806, 
etc. Neither the character string "Jones", nor the Integer 
"505" alone necessarily carry any Information. 

At the time when a data element first enters the 
system, it is assigned a unique Identifier which Is used 
thereafter to reference it. This Identifier is the 
Reference Number (RN), and In the current Implementation Is 
a 36-bit bit string which may be referenced as an Integer. 
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RN's are not basic to the system; they are used for 
computational and storage efficiency. Programs called Data 
Element Modules (DEM's) are provided which obtain Data 
Elements as input, convert them to the internal storage form 
(the Standard Form, SF), store them in DES's, and assign 
their Reference Numbers. DEM's are also called to output 
SF's In human-readable format. Thus there might be a DEM 
which handles dates, one which handles names, one which 
handles integers, and so on. 

In order to construct and manipulate RDS's, 
programs called Relation Strategy Modules (RSM's) are 
provided. There is one RSM for each storage strategy 
supported by the system; thus, there might be an RSM for 
list structures, an RSM for trees, etc. In the example 
above, the RDS is represented as an array, and the DE's are 
shown as being in the tuples of the array. This 
representation suffices for the logical content of an RDS 
and will be used throughout this paper, but It should be 
remembered that RDS's are not necessarily arrays, and that, 
in any event, in the current Implementation they contain the 
RN's of the DE's, not the DE's themselves. 

Each RSM provides the following set primitives for 
manipulating RDS's: 

intersect ion 
difference 
project Ion 
join 
compos it ion 
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product 
un Ion 



These operations require two RDS's as input and produce a 
new RDS which contains the result of the operation. 
Intersection and union perform In the obvious manner; 
difference yields all members of the first input which are 
not in the second; projection removes unwanted fields or 
permutes fields; join forms an RDS which contains all the 
fields of both inputs along with those tuples which match on 
the inputs' common fields. Composition requires that the 
last field of the first input be the same as the first field 
of the second, and It produces an RDS which does not contain 
the common field, but does contain those tuples which 
matched. Product Is the Cartesian product. 

In addition, several non-set primitives are 
prov Ided: 

A set Is ordered by use of 
get_successor 

For a given tuple, get_successor returns the next tuple In 

sequence. 

For efficiency the operations 

replace_tuple 
f lnd_tuple 

are defined. Both are redundant In that they could be 
performed by combinations of set primitives. FInd_tuple 
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searches an RDS for a given tuple; replace_tuple replaces a 
tuple in an RDS. 

The mechanisms for creating RDS ' s are also 
f urn ished: 

create_set 
insert_tuple 

The create_set operation is used to define a new RDS / and 
takes the necessary steps to establish its storage, its RD, 
and its associated OEM's and RSM. Insert_tuple inserts a 
given tuple Into an existing RDS. Thus these two operators 
provide for original data entry Into the system. 

For details of the functions of these operations/ 
the reader Is referred to (25). 

In addition to the Reference Numbers assigned by 
DEM's, there are two special RN's: the "wild card", 
represented by "*", which is considered to match any RN; and 

the null RN, represented by " ", which Indicates a null 

DE. Thus the tuple 

<*, *> 
matches any of the three tuples in the above example. The 
tuple 

<Jones, *> 
matches <Jones, 505> above, and would also match any other 

Jones's in the RDS. The tuple 

<Jones, > 

matches none of the above tuples, but would find any Jones's 



k. MADAM Page 30 

who had no offfce in the RDS. 

^.2. Impl ications fojL Access Control 

The philosophy and the design of MADAM have 
several implications for the design of its access control 
mechan isms . 

The set operations provided by MADAM are powerful 
in that they allow concise specifications of large amounts 
of work. The access control scheme must provide similar 
power through conciseness of expression, or it will 
significantly detract from MADAM's usefulness. In a company 
employing 50,000 workers, for example, It might be entirely 
unacceptable to specify access to a particular RDS by a list 
of names: an access list of 3,000 people would be entirely 
unmanageable. 

Moreover, the fact that data bases might be very 
large Implies a great deal of sharing of physical data 
between users who have widely varying characteristics and 
Information needs. A rather fine distinction of the logical 
types of access to a data base Is needed, so that precise 
levels of control may be applied In a variety of 
circumstances. The term "read access" is too coarse a 
distinction to be useful. 

Last, the use of set operations to obtain 
information from the data bases implies a large number of 
temporary RDS's containing either Intermediate results pr 
special relations which are useful for some application. A 
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single interaction with the main data base might cause the 
creation of several new RDS's. Therefore simple-minded 
schemes for assigning access privileges to new files are 
insufficient; a fixed default would not characterize 
properly more than a few of the new sets. In addition, 
placing the burden of assigning access privileges for new 
sets on the originator of sensitive information would 
discourage almost anyone from storing such information in 
the system. Even Welssman's ADEPT-50 scheme Is far too 
simple; MacAIMS access control must provide the originator 
of sensitive information with much more significant aid In 
assigning access rights to new RDS's'. 

The access control schemes presented In Section 3 
have chosen positions along the four dimensions of access 
control which are too naive for the purposes of MacAIMS. We 
turn now to the design of a scheme which exhibits much more 
power and generality. 
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5. THE MACAIMS INTERIM ACCESS CONTROL SYSTEM 

This section describes the initial access control 
mechanisms for MADAM. The system outlined here is an 
"interim" system in the same sense that MacAIMS itself Is In 
an interim state: we do not at this time fully understand 
all the problems (let alone their solutions) associated with 
access control. Therefore, a first approximation access 
control system Is provided which will yield a simplified 
solution to the general problem as well as a base from which 
to experiment with more powerful algorithms for control . 
Moreover, the system described here Is "primary" In that It 
Is limited to the issue of Interaction of an identified user 
with system Information. 

The Interim access control system Is considered 
first at the level of basic assumptions, then at the user's 
level, and finally at the system design level. 
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5.1. Bas ic Assumpt ions 

In order to delimit a common ground for discussing 
the primary access control problem in the context of 
MacAIMS, the following basic assumptions are enumerated. 
5.1.1. Def ini t ion of Access Control 

For the purposes of this study, the following 

definition of access control is sufficient: 

Access Control is defined as the restriction of the usg 
and dissemination of sensitive information to 
authorized ent it ies . 

This definition merits further clarification: 

Entity is defined to be the party requesting 
access. Roughly speaking, this Is the user of the system, 
but the intuitive meaning of "user" is insufficient for our 
purposes. In MacAIMS the requesting entity corresponds more 
nearly to the concept of a "computat ion", as expressed by 
Dennis and VanHorn (7), and is precisely defined by a list 
of characteristics associated with the state of the system 
at the time access is requested. The list includes as a 
minimum the standard Multics identification characteristics: 

1) User_id (name) 

2) Project_id (project) 

3) Instance tag 

and may be arbitrarily extended to Include any other 
information about which MacAIMS has knowledge or can be made 
to obtain knowledge. Such extensions logically include 
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characteristics like: 

h) Terminal_id (the terminal identifier of the 

process requesting access. This characteristic is 

fairly commonly used in military security systems/ and 
will be provided in MacAIMS for the sake of generality/ 

but it is not considered to be especially secure for 

the purposes of access control/ since terminal id's are 
relatively easy to change.) 

5) Program_id (the procedure requesting access.) 

6) Time of day 

7) Day of the week 
etc. 

Informat ion in MADAM is considered to reside only 
in Relational Data Sets. It is therefore those sets which 
are to be protected. 

Information is sens ? t ive as long as there are 
conditional restrictions on its use or dissemination. Such 
restrictions may be placed on information either by its 
originator or by any other party to whom he grants that 
capability. If all fields of an RDS have the maximum 
possible access rights, then the information is not 
sensitive, and the access control system need no longer be 
concerned with it. The possible levels of sensitivity 
allowed by the interim access control system are described 
in Section 5.2.1. below; the procedures and data which 
describe the conditions of sensitivity may be completely 
arbi t rary . 

Use of information is defined by an operator which 
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an entity requests be applied to that information. In the 
interim system, possible operators are restricted to those 
performed by Relational Strategy Modules, i.e., the set 
theory operators and the non-set primitives. 

D i sseminat ion of information is distinct from use 
by virtue of being a "final result" from the system's 
viewpoint. Dissemination implies the passing of information 
beyond the boundary of the access control system's ability 

to restrict. 

An entity is authorized to request an interaction 
(a use, a dissemination, a write, an append, etc.) with 
existing information if his characteristics and the 
operation's nature and the result of the request satisfy the 
sensitivity constraints which have been placed on the 
information. It will be demonstrated that al 1 of these data 
must be considered in determining permissible access levels. 
In the interim system, the levels of authority granted (as 
well as the levels of sensitivity) are constrained to fall 
into a fixed set of access capabilities described below. 

Finally, restriction is the act of constraining 
information accesses to those authorized in the above sense. 
5.1.2. 5 Y n pm Characteristics 

The following general (and rather obvious) 

characteristics are desired in the Interim access control 
system. 

In order to be immediately useful, the Interim 
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system must be general in the same ways that MADAM itself is 
general. It must not place any restrictions on the nature 
of the actual information which it protects. Second, and 
somewhat more difficult, it must allow considerable 
flexibility in the ways the owner of sensitive information 
may express the conditions of sensitivity. 

The system must be extensible since it will not be 
a complete solution to the problems of access control. It 
must eventually be extended to include solutions to the 
problems which it does not now solve, as well as solutions 
to problems which we have not forseen. Since the decisions 
along each of the four dimensions of access control 
discussed in Section 1 are arbitrary, it must be relatively 
easy to change those decisions as experience dictates. More 
important, individual users must be able to extend the 
access control mechanisms in arbitrary ways to handle their 
own special requirements for control. 

There must, however, be some limit to these 
arbitrary extensions, lest the situation arise where every 
user has his own access control system which is so 
specialized to his needs that it cannot communicate with any 
ether user's system. The interim system provides this 
common framework for communication by fixing the set of 
assignable sensitivity (and authority) levels. The set, 
however, is fixed by choice, not by any inherent limitation 
of MacAIMS. 
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The interim system must be compat ible with the 
rest of MADAM in the sense that it utilizes both the data 
storage mechanisms and the operational mechanisms provided 
by MADAM to do its work. It is this compatibility which 
provides the interim system with the ability to meet the 
first two design goals. In addltion / the access control 
system gains great power because the large body of tools 
available in MADAM become available for manipulation of 
access information. Moreover, compatibility means that as 
MADAM becomes more powerful, the access control system will 
gracefully evolve in a similar fashion. 

Lastly, the cost of controlling access (in terms 
of both user effort and computation time) shoul d vary 
d? recti v with the complexity of the sensitivity description 
of the data; detailed and sophisticated descriptions should 
be expected to cost more than simple ones. Any user who 
wishes to interact with someone else's sensitive data should 
expect to pay in proportion to that sensitivity. Moreover, 
a user who does not desire protection should expect his 
costs to be somewhat lower. 
5.1.3. Design Assumptions 

Other assumptions upon which the following 
description is based are those implied by Section 2.2. 
above: namely, the entire range of access control problems 
that physically exist between the user station and the CPU 
are not considered. All Information concerning the user's 
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identity and the other characteristics which identify the 
requesting entity is taken to be accurate; verification of 
that data is a separate problem. 
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5.2. Pes fen Spec i f icat ions 

This section outlines/ from the user's viewpoint/ 
the interim access control system's appearance and behavior. 

At the outset it should be noted that it is not 
feasible to store access control information on a tuple by 
tuple basis in MacAIMS/ even though the tuple is the basic 
unit of information. Such schemes would require more 
storage and computation than reason permits/ and would make 
the user's task in specifying access control information 
impossibly large. This does not Imply that one cannot 
specify constraints that affect single tuples or small 
groups of tuples within an RDS. Even in these cases, 
however, the access control information Is not physically 
attached to the individual tuples. 

tt is also unreasonable to provide access control 
on an RDS by RDS basis, since this level of control is too 

superficial to allow sufficiently general specifications of 
sensitivity. Suppose, for example, that the RDS <Name/ 
Salary/ Rel igious-Af f i 1 iat ion> were created. Both salary 
and religious affiliation would probably be sensitive, but 
there is no reason to believe that the nature of the 
sensitivities would be the same. Access control information 
is therefore retained on a f I el d bv field basis within 
Relational Data Sets. 
5.2.1. Access Capabil ities 

A user may request the transfer of information 
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from an RDS lo himself for two (and only two) logical 

reasons -- he may wish to use the information as data in 

calculating other information which he needs (i.e., he may 

wish to use it in the sense of Section 5.1.1.) or he may 

wish to view the information itself as a final result (he is 

requesting dissemination). However, the concept of "use" Is 

still too general for access control. It is necessary to 

distinguish still further, and for the interim system, "use" 

has been split into two categories: manipulative and 

statistical use. Manipulation means the application of the 

set theory operators provided by MADAM; statistical use is 

the extraction of means, medians, and so forth. This 

subdivision is strictly hierarchical, so that the concept of 

"increasing access" will have meaning. 

Thus there are the following four levels of access 

for Information which flows from an RDS ±& a user. In 

increasing order (by the amount of information which they 

release) they are: 

N — null; no access is permitted. (This is the 
default access unless the originator of the information 
specifies otherwise.) 

M -- manipulate; the user is permitted only to apply 
set theory operators to the information. He may or may 
not be allowed to see the results of that manipulation, 
depending upon the access restrictions of the data. 

S -- statistical; the system will permit dissemination 
of statistical data about the Information only. 

P — print; the system will disseminate the 
informat ion . 
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Each of the lower access capabilities is 
considered to be a proper subset of the next higher 
capability. Thus S. access includes the right to manipulate 
the information. 

It is implicit in the above statements that the 
programs which the user invokes in order to apply set theory 
operators or statistical operations are either standard 
MacAIMS programs or other programs whose performance has 
been "guaranteed" to the access system's satifaction. In 
order to apply arbitrary programs to protected data, the 
user must possess the capability to have the information 
disseminated (£ access). 

The division of "use" into N, £, and M is clearly 
somewhat arbitrary. It might, for example, be desirable to 
provide even finer levels of distinction by further dividing 
,£. into the capability for extracting the mean, the 
capability for extracting the standard deviation, and so 
forth. It would seem, however, that the divisions expressed 
here are at about the appropriate level of distinction for 
most management data in the context of MacAIMS; only 
experience with using the system will allow us to judge more 
surel y . 

Similarly, there is a hierarchy of capabilities 
for the flow of information from an entity £o_ an RDS. These 
capabilities are essentially those provided by Multics, 
except that they are viewed as a strictly ordered hierarchy 
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of privilege rather than as discrete but equal divisions. 

In increasing order, they are: 

N -- null; no access is permitted. (This is the system 
default.) 

A — append; the user may append relations to the 
"end" of the RDS (where "end" is the logical, not the 
physical, end), but he may not change information which 
is there al ready. 

W — write; the user may change existing information 
or add information to the RDS. 

C -- change access; the user may manipulate the access 
control data which is associated with the fields of the 
RDS. 

There are in addition two capabilities associated 

with each RDS with which the user need not normally concern 

himself, since they are assigned and maintained by the 

system. They are: 

-- ownership; the owner of an RDS is the user who 
caused its creation. He may therefore delete It. 
(Note that this does not imply the £ capability or any 
other; an acquired data set belongs to whoever caused 
its creation, but has access capabilities determined by 
the sets which were used to derive It. Thus a user may 
derive a set to which he has no access; however, since 
he owns it, he can get rid of it.) 

Ac — acquired; an indicator that the RDS contains 
Information which was not originated by the owner. A 
data set is acquired unless 1) it was created through 
the use of the primitive operations "create_set" and 
"insert_tuple" or 2) Is made from RDS's which were not 
acquired and which are owned by the user in question. 
The acquired flag being off Implies the C. capability. 

Thus in the MacAIMS access control system, there 

are three distinct concepts which In more conventional 

systems are lumped together under the term "owner". First, 

there is ownersh ip „ which Implies responsibility for 
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creation of an RDS and the right to delete it. Second, 
there is the concept of the originator of information 
(acquired flag off), which Implies original entry of all 
data in the RDS and therefore the rights of ownership and 
access changing. Last, there Is the ability to change the 
access control specifications, which falls to the originator 
and to whomever else he specifies. The Interim system does 
not, therefore, provide mechanisms for resolution of 
conflicts of privacy. Such issues must be solved through 
extensions of the current scheme, 
5.2.2. Description o_f_ Access Rights 

It Is clear that In the non-mil Itary world there 
are many different ways In which one might wish to specify 
sensitivity constraints on Information which Is to be 
protected. In the simplest (and probably the most common) 
case, one might list all the people who can (or cannot) 
access the Information, along with what type of access they 
have. Such a scheme Is supported by Multlcs. There are 
many cases, however, where such a listing Is either 
Inconvenient or Impossible. It Is therefore desirable to 
provide more powerful mechanisms for specifying the 
conditions under which one's Information should be released. 
Such statements as "Anyone may see Information about 
himself" or "Anyone above the level of plant manager may see 
the personnel data" should be concisely expressible. It Is 
not possible, obviously, to delimit every way in which such 
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constraints might be stated, nor would one support them all 
if it were; the access system must be simple enough to be 
comprehended if it is to be used. Support is therefore 
provided for a number of ways to express access control 
restrictions which should be general enough for most 
purposes. In addition, we provide a mechanism by which the 
originator of information can specify procedures of his own 
choosing for access control. 

The originator of information and those users to 
whom he has granted the C. capability may specify, for each 
level of access capability, conditions for its release by 
the fol lowing tests: 

l) Test or xhs. lis! £f characteristics o_f xhs. 

request ing ent I tv : He may specify tests to be made on any 

of the characteristics of the requesting entity listed in 

Section 5.1 above and included in the state set of the 

system (see "The Access Control Data Base", below). Such 

tests logically take the form 

"Jones has P access" 

"if <user_id> = Smith and <terminal_?d> = a6k and <day> 
= Friday, then access = M" 

and so forth. They may also be "negative" specifications, 
such as 

"if <user_id> -= Smith then access = P" 
With this test, as with all others, a default access may be 
specified which is logically equivalent to an "else" clause 
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and which will take effect if all tests fail. If no default 
is given, the system default is null; the system is 
basically closed rather than basically open. 

2) Test on the content of the sensi t ive doma in : 
He may specify access restrictions based on the content of 
the field in question. For example/ if salary is a 
protected field, a constraint might take the form: 

"if <salary> = 100000, then access = N" 
The interim system supports only statements which are 
expressible in terms of the existing MADAM operators, i.e., 
only matching is allowed. This implementation restriction 
probably makes tests on content alone less useful; one 
would generally want to make statements such as "if salary 
is less than 10000 then...". This simple "less than" 
constraint would be easy to handle, but it is a special case 
of the problem of subsetting based on general logical 
restrictions (which is under study at MacAIMS) and will 
therefore not be solved separately. For the present such 
constraints must be handled by special programming. Since 
the access control system uses MADAM constructs exclusively, 
however, such capability will be available to the access 
system when it is available to the rest of MADAM. 

3) Test on the context in which the sensitive 
domain appears : He may specify constraints based on the 
context in which the field in question may appear. These 
context restrictions may be based only on the fieldname of 
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the other f lei d, i.e. 

"salaries may not be printed in conjunction with names" 

or they may be based both upon the fieldname and its 
content: 

"salary may not be released if it is seen in conjuction 
with name and name = George" 

The first of these will be called a simple context 
restrict ion , the latter, complex . This distinction is 
necessary for computational purposes, as described in 
Section S.k, but is not basic to the logic of access 
control . 

k) Proper completion &£ an interactive procedure: 

He may specify that users supply a password (perhaps a 

procedural password as described in Section 2) at the 

console in order to obtain access. The system interactive 

access routine will provide for one challenge and response; 

any more fancy interaction will require special purpose 

programming. 

5) Anv combination of methods 1 - £: He may 

specify combinations of the above; for example, 

"Jones may see salaries if salary appears in 
conjunction with the field <group>, and the contents of 
<group> are the same as his project id" 
(requesting entity characteristics + complex context.) 

It is felt that this level of support of access 
description is general enough to handle the majority of 
MacAIMS access problems. At the same time, by allowing the 
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user to specify access control by stages, considering first 
the system state, then the content of the field, etc., the 
system should be reasonably easy to use. Moreover, the 
simpler the restrictions, the simpler they are to specify. 
5.2.3 Acquired Relation Sets 

A relation set is "acquired" only if it is 
obtained by combining existing relation sets that contain 
information which was not originated by the owner. Thus 
(obviously) all acquired relation sets are agvv sets, but 
(not so obviously) all new relation sets which are the 
output of a set operation are not acquired sets. If a user 
combines sets which contain only information which he 
originated, the new set is conceptually identical to a set 
formed by using "create_set" and " insert_tuple", and it is 
therefore not acquired. In MacAIMS as It now stands, sets 
are acquired only through the standard set operations 
provided by the RSM's; presumably it will one day be 
possible to derive sets by other means. 

In any event, it is the system's responsibility to 
maintain appropriate access control to information in 
acquired sets. Not only are access privileges automatically 
assigned to the acquirer, but also an Access Control List is 
assigned to the acquired set which will maintain proper 
control even if the set is passed on to other users. 
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5.3. System Overview 

This section provides an overview of the design of 
the Interim Access Control System. The access control data 
base and the MacAIMS Access Restriction Module (MARM) which 
is responsible for maintaining that base and for using it to 
control access are described here; subsequent sections 
discuss in detail the representation of access information 
and the rules for computation of access rights to acquired 
relation sets, as well as methods for defining access rules 
in non-standard ways. 

MARM is the overseer program for access control/ 
and is invoked at each attempted access to sensitive 
information. The other major program modules which assist 
it are the access handlers, each of which evaluates its data 
and returns a boolean value Indicating whether its 
constraints are satisfied, and the RSM for evaluated 
functions, which maintains RDS's whose tuples require 
function evaluation. In addition, the ACL_bui1der provides 
aid in constructing Access Control Lists. 
5.3.1. The. Access Control Data Base 

The following pages detail the access control data 
base as it logically exists within MADAM. In some cases, 
the physical data base may differ slightly from the logical 
data base for reasons of programming expediency, but such 
differences are not relevant here. 

It is implicit in the discussions of Sections 5.1 
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and 5.2 that there are two general classes of information 
which are necessary for access control. First, there is 
information which pertains to the characteristics list of 
the entity requesting access; second, there is information 
which details the nature of the sensitivity of information 
to which access is requested. All information regarding the 
characteristics of the requesting entity resides in the 
"state set" of the system, which has the form of a MADAM 
RDS, and all information regarding the sensitivity of the 
fields of RDS's resides In the "Known RDS Table" and its 
associated Access Control Lists. 
5.3.1.1. Requesting Entity Information : IhS. State 2£± 

The state set is logically a single tuple of 
degree n where n is the number of characteristics associated 
with the requesting entity. tt Is an RDS with only one 
entry besides the relation descriptor, and has the form: 

<User_id, Project_Id, lnstance_tag, Terminal_!d, , 

Program_id, Time, ...> 

"..." represents any other Information which the system 
chooses to support for access control purposes; such 
choices should be based on user demand. <Program_id> 
includes both the program name and entry name of the program 
active when the attempted access occurred. 

The state set Is accessed via the 
RSM_evaluated_functions_, and Is a special case of the 
larger class of RDS's which that RSM supports. An RDS 
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Associated with each data base In the system Is a 

(logical) RDS called the Known RDS Table (KRDST). The KRDST 

is made up of two physical RDS's. The first/ called the 

KRDST, has the form 

<RDS_name, . .., Ownership, Acqui red_f 1 ag, 
Restrict ion_f lag, Fal se_content_f lag, 

Fal se_context_f lag, Tlme_of_reference, ACL_control__rds> 

where ACL_control_rds points to the second part of the 
KRDST, which is called the ACL_control RDS, and has the form 
<FIel dnumber, Access, ACL_rds> 

The user's data base begins with an empty KRDST; 
I.e., no RDS's are known to him. At the first requested 
reference to an RDS, an entry In the KRDST is made, and the 
user's current access privileges to each of the n fields of 
the RDS are evaluated and stored In the <access> indicators 
of the ACL_control . When a set operator Is performed which 
results In the creation of a new relation set, the Input 
sets are checked against the KRDST and entered If necessary, 
and the new set is appended in a similar fashion. 

The fields of the KRDST and their uses are as 
fol lows: 

1) RDS_name (the name of the Relation Data Set) 

2) ... (other Information which the system needs 
to keep regarding the RDS, but which Is not directly 
related to access control; this might Include pointers 
to the physical location of the segment, etc.) 

3) Ownership (the Indicator of whether the RDS Is 
owned by this user, as described In Section 5.2.1.) 
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k.) Acqu i red_f 1 ag (the Indicator of whether the RDS 
is acquired, as described in Section 5.2.1.) 

5) Rest r ict ion_f 1 ag (on if there are content or 
context restrictions on any field of the RDS) 

6) Fal se_content_f 1 ag, Fal se_context_f 1 ag (for a 
acquired set, an indicator of whether operations have 
been performed in the derivation history of the RDS 
which make it impossible for the access control system 
to guarantee that the content/context is "True." This 
problem is discussed in detail in Section 5.5. For a 
set which is not acquired, the flags are off.) 

7) Time_of_refe rence (the time of the last 
reference to the RDS) 

8) Fieldnumber, Access, ACL_rds (These represent 
the information necessary to compute access to field 
<f iel dnumbe r> of the RDS in question. <Access> is the 
user's currently computed access privilege level, and 
is computed at the time the KRDST entry is made from 
the information contained in the ACL's which are 
pointed to by the ACL_rds's. (In the case of an 
acquired data set, it will be computed from the ACL's 
of the input RDS's). At each reference to the RDS, the 
Time_of_reference is checked against the time of last 
modification of the ACL's pointed to by the ACL_rds's, 
and if they have been changed, access is recomputed 
before any information is released. More than one ACL 
may be associated with a particular field (this occurs 
primarily with acquired relation sets). Multiple ACL's 
are represented by multiple entries in the ACL__cont rol ; 
in these cases, all of the ACL's for field ± are 
evaluated, and the minimum returned access is assigned. 
This is equivalent to logical "and": if ACLj.1 
specifies £ access under conditions j(, and ACLJ.2 
specifies P access under conditions Y_, then £ will be 
granted to field ± only if X "and" Y is true. The 
methods for computing the access level and for 
determining the ACL of an acquired data set from the 
ACL's of its inputs are discussed below.) 



There is one KRDST per data base in the system. 
Note that some data bases may be temporary (per Multics 
process), and as such will be destroyed when the user logs 
out unless explicitly saved. 
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The ACL's (which may be the same for many RDS's) 
are themselves RDS's with the following format: 

<Access_level , And_flag, Access_handler, Data_type, 
Data_rds> 

The meaning of the fields are as follows: 

1) Access_level , Access_hand1er, Data_rds 
(Access_handler is the name of a program which may be 
either system supplied or user supplied and which 
operates on the data structure pointed to by Data_rds 
in conjunction with such system state data as necessary 
to return one of two values — either "The conditionals 
specified are satisfied", (True) or "The conditionals 
specified are not satisfied". (False) If the response 
is True, then the permissible level of access is that 
implied by Access_level . ) 

2) And_flag (used to link together entries of the 
ACL as being part of the same conditional 
specification. If two (or more) tuples are linked 
together by the And_flag, both access handlers must 
return true in order for Access_level to be granted. 
This Is a logical "and", and tuples linked in this way 
are called And groups . ) 

3) Data_type (specifies the nature of the data 
pointed to by Data_rds.) 

Entries in each ACL are in decreasing order by Access_l evel . 
At this point it is possible to draw the logical 
structure of the access control data base, as shown in 
Figure 1). 
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5.3.2. MARM : The MacAIMS Access Restriction Module 

It is MARM's responsibility to oversee the access 
control data base, to keep it up to date by assigning access 
appropriately to RDS's in the KRDST, and to perform the 
function of restricting access to authorized entities. 

MARM "evaluates the access" for a_ particular field 
1 of an RDS by the following procedure: 

1) For each tuple in the ACL_control whose 
<Fieldnumber> entry is 1, "evaluate the associated ACL". 

2) Assign the minimum access level returned by 

these evaluations. 

The procedure for "evaluating an ACL" is: 

1) For each tuple in the first And_group (there 
may be only one tuple), call the access handler; if all 
handlers in the group return True, the access level Is 
<Access> . 

2) If the first And_group fails, try the second, 

etc. 

3) If all And_groups fail, assign the 
originator-supplied default access. 

k) If the originator supplied no default, assign 

N- 

Thus, evaluating access to a field of an RDS is 

essentially a process of executing a list of programs (the 

access handlers) until one of those programs decides that 

the situation satisfies its conditionals. This process is 
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made somewhat more compl icated by the need to "and" these 

programs in order to allow mixed tests, and by the need to 

"and" the ACL's in order to preserve access rights through 

acquired data sets. Whole ACL's may be "and"ed on the 

ACL_control RDS by use of the <f iel dnumber> / and individual 

tuples within an ACL may be "and"ed by use of the And_flag. 

In any other case, separate tuples in the 

ACL_control or an ACL imply logical "or". For example, the 

ACL: 

Access Level And Flag Access Handler QJ_ DRefnum 
P 1 Progl - Datal 

P 2 Prog2 - Data2 

is equivalent to the logical expression: 

"if <Progl's conditionals) cj: <Prog2's conditionals) 
then access = P" 

whereas the ACL 

Access Level And Flag Access Handler QT DRefnum 
P 1 Progl - Datal 

P 1 Prog2 - Data2 

is equivalent to the logical expression: 

"if <Progl's conditionals) "and" <Prog2's conditionals) 
then access = P" 

At each invocation MARM performs the following 
steps: 

1) It checks the appropriate KRDST entries for the 
input RDS or. RDS's; if they are not already known to the 
user, it makes them known, evaluates the access to each of 
their fields, and makes appropriate entries In the KRDST. 
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2) It checks whether the operation is a non-set 
primitive. If so, it decides whether an access violation is 
implied, either does or does not permit the operation, 
updates the KRDST, and returns. 

3) If the operation is a set primitive, then it 
will result in a new (perhaps acquired) RDS . MARM makes an 
entry in the KRDST for the new set, and computes its 
ACL_control. The ACL_control entry for each field is the 
union of the ACL_controls of the corresponding fields of the 
input RDS's, with the <f iel dnumber> field appropriately set. 
Thus the new ACL_control will cause MARM to perform the 
logical "and" of the input ACL's. If both input fields had 
the same ACL_control, then the new ACL_control (and hence 
the ACL's themselves) is the same as that of the inputs. 
Notice that this algorithm gives new RDS's only a pointer to 
the actual access control data from the input sets. Any 
subsequent changes in that data will therefore be reflected 
in derived sets; of course, this characteristic may be 
overridden by supplying copies of the data instead of 

pointers . 

k) MARM now assigns the current access privileges. 
If the set operation is neither intersection nor difference, 
the access level for each field is the minimum of the access 
levels of the corresponding fields of the inputs. For 
intersection and difference, the new ACL_control for each 
field is evaluated in the above manner, and the resulting 
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access rights are assigned. It is thus possible to obtain a 
subset (by intersection or difference) to which one has 
access priyileges higher than his privileges to the original 
set . 

5) In either case/ MARM decides whether an access 
violation has occurred, takes appropriate action, updates 
the KRDST, and returns. In the interim system, the response 
to an access violation is a denial of the request. It would 
be simple to make this action either more severe (ring 
alarms, log the user out) or less severe (release whatever 
Information he was really allowed to see), as the situation 
might warrant. 
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5.4. Uig. Standard Description o_f Sensitive Data 

This section addresses the problem of describing 
the logical constraints placed upon sensitive information. 
The requirement for compatibility with the existing MADAM 
system implies 1) that MADAM constructs be used for storing 
the access control data, and 2) that MADAM operators be used 
to operate on it. In fact such constraints may not be 
concisely expressed in MADAM as it now stands, but the 
compatibility requirement overshadows such considerations. 

These descriptions of sensitivity are the RDS's 
pointed to by the <data_rds> field of the ACL when the 
<access handler> is a system-supplied program. 

The essence of the solution which the interim 
access control system adopts is the construction of one or 
more filtering relations. A +Filter RDS represents 
information that may be accessed; a -Filter RDS represents 
information that may not be accessed. Then, given an RDS to 
evaluate (the Requested RDS ) , a system access handler 
logically intersects it with the filter RDS; the result of 
this intersection is the Accessible RDS. For a +Filter / the 
Requested RDS passes if the Accessible RDS contains exactly 
the same information as the Requested RDS. Since the 
+Filter represents information which can be accessed, all 
the information in the Requested RDS must get through or 
else the Requested RDS contains Inaccessible data. For a 
-Filter, the Accessible RDS must be empty in order for the 
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request to be valid; any information which gets through the 
filter is data to which the user does not have access. 

In the interim access control system, the standard 
access handlers use the set primitive join instead of 
intersection, because join ignores fields which the input 
RDS's do not have in common. Thus filters may be 
constructed without regard for fields which are irrelevant 
for access control. This fact facilitates sharing of both 
filters and entire ACL's between RDS's. 

The logical operators used in expressing 
constraints are "and", "or", and "not". We have already 
seen that adding tuples to an RDS may serve as a logical 
"or"; this equivalence also holds within filter relations. 
In addition, the <f iel dnumber> field of the ACL_control and 
the And_flag of the ACL, when coupled with MARM's evaluation 
rules, provide two methods for specifying logical "and". 
Adding fields to a filter is yet another way of specifying 
"and": examples below demonstrate that "and" is Implied 
between fields of an RDS on a tuple-by-tuple basis. (Thus, 
a filter containing only "or" constraints has order one.) 
The "not" operator is represented by a -Filter. 

The precise rules by which a requested RDS may 

pass a f i 1 ter are: 

+Fi Iter : 1) The join must match all fields of the 
filter (=> order of the Accessible RDS = order of the 
Requested RDS.) and 2) the number of tuples in the 
Accessible RDS = the number of tuples in the Requested 
RDS. 
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-F i 1 ter : For simple context filters, the join 
must fail (=> no fields match). For all other 
-Filters, 1) The join must match all fields of the 
filter, and 2) the number of tuples in the Accessible 
RDS = 0. 

The <Data_type> field of the ACL indicates which type of 
filter is pointed to by <Data_rds>. Use of these constructs 
and the evaluation process are best made clear by examples. 
5.U.I. State Set Constraints Alone 

Filters for state set constraints alone are the 
simplest because the structure of the State Set RDS is fixed 
by convention. Thus the context of any state set entry Is 
fixed and the join operation will always match on all 
fields. The "*" convention may therefore be conveniently 
used in adding constraints. 

Suppose, for example, that the Initial constraint 

on a field is 

"if <User_id> = Smith | <User_id> = Jones | <User_id> = 
Hil phenhauser, then access = P" 

The resulting +Filter would simply be: 

User id 

Smith 

Jones 

HI 1 phenhauser 

The result of joining this RDS with the State Set RDS is an 
RDS which contains one tuple if the current user Is Smith or 
Jones or Hi 1 phenhauser, and which contains tuples 
otherwise. Since the State Set is one tuple long, it passes 
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the filter only under the correct conditions. 

Now suppose we wish to add the (completely 

independent) constraint 

"if <terminal_id> ■ a6k then access = P" 

This may be accomplished by adding a field to the existing 

+Fil ter: 

User id Terminal id 

Smith * 

Jones * 

Hi lphenhauser * 
* a6k 

The first tuple of the filter now precisely expresses the 
constraint 

"if <user_id> ■ Smith & <terminal_id> = any terminal, 
then access = P" 

but this is no different than the original constraint, since 
all users must be logged in at some terminal. The last 
tuple In the filter matches anyone logged in on terminal 
a6k, as desired. Thus constraints may be added without 
regard for previous tuples, as long as "*" entries are 
appropriately added. 

A -Filter for state set constraints Is constructed 
in exactly the same fashion. The join must yield an empty 
Accessible RDS to satisfy the constraints. 
5.4.2. Content Constraints Alone 

Constraints which involve only the content of the 
sensitive field are also easy to construct. Such 
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constraints do not involve logical "and"s, and the filters 

are therefore of order 1. Suppose, for example, that 

<religion> is the sensitive field, and the constraint is of 

the form 

"if <religion> = Methodist | <religion> = Catholic, 
then access = M" 

The +Filter is then 

Methodist 
Cathol ic 

The access handler joins this filter with the Requested RDS, 
and the rules for passing are the same as above; new 
constraints are formed by adding tuples. A -Filter would 

work similarly. 

5.U.3. Context Constraints Alone 

Context constraints alone are more difficult than 
either state set or content constraints because it cannot be 
guaranteed in advance that a filter applied to an arbitrary 
RDS will match on all fields. This fact means that the "*" 
cannot be used in the same fashion as In the above examples. 

Suppose that <salary> is the sensitive field, and 
that context constraints are to be specified. 

Simple context constraints are easily 
representable. if the constraint is of the form 

"if <<f ieldname>> ■ <social security number> then 
access = N" 

then the filter is 
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social security no 



If the simple context constraint is a -Filter, the form is 
the same, but the rule is that the field must not match. 

Now suppose that the user wishes to express two 
constraints on the <salary> field, namely 

"if <soc. sec. no.> = 100-10-1000 then access = P" 
and (independent of that) 

"if <name> = <User_id> then access = P" 

One's first inclination might be to create the filter 

najlfi soc. sec, no. 

<user_id> * 

* 100-10-1000 

This filter, however, is inappropriate. By the rule that 
all fields must match, the first tuple specifies that both 
name and social security number must appear, and name = 
<user_id>; the second tuple is interpreted similarly. These 
are n9t the constraints specified. Moreover, adopting a 
rule that only one (or more) fields must match would not 
solve the problem -- this filter would then pass any RDS of 
the form <soc. sec. no., salary>, due to the "*" in the 
first tuple, and any RDS of the form <name, salary> due to 
the "*" in the second tuple. 

Thus specifying "or" constraints on separate 
fields of the context requires separate filters. Filters of 
more than one dimension have "and"s between the fields. 
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Only in the case of the state set may these "and"s be 

ignored. 

5.4.4. Interactive Constraints Alone. 

The interactive access handler is identical to the 
state set access handler, except that it uses an RDS of the 
form 

<User_id / Password> 

instead of the state set RDS. This RDS, called the Password 
Set, is also maintained by RSM_eval uated_funct ions_, and it 
contains the flagged RN's for <user_id> / and <password>; 
therefore any reference to it causes calls to functions 
which obtain the user's name and a password from the 

consol e. 

Pure interactive constraints are of the form 

"if <user id> = Smith & <password> = openup, then 
access = P 1 * 

and are represented in a +Filter RDS as 

User id Password 

Smith openup 

Use of the interactive access handler is analogous to use of 
the state set access handler. 
5.4.5. Combinations of Constraints 

Combination of the various types of constraints is 
an extension of the filtering concepts presented above. The 
physical representation of compound constraints is 
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determined by the nature of the particular expression. In 
some cases more than one storage scheme for a given compound 
constraint is possible because of the three different 
representations of "and". In these instances the normal 
action should be to fit as many constraints as possible into 
one filter, in order to minimize both storage for ACL's and 
execution time for MARM. On the other hand, if a particular 
filter is sufficiently general that it may be shared between 
a number of different RDS's, one would not insert an "and" 
constraint if such an addition would render the filter 
unsharabl e. 

The above examples demonstrate that context 
constraints may be "and"ed into the same filter if the 
meaning of the constraint is 

(<context constraintl>) & (<context const ra int2>) . 
In the same fashion, a content constraint may be "and"ed 
into a context filter. Thus if <salary> is the sensitive 
field, the constraint 

"if (<salary> = 10000) & (<group> = EE) then access = 
P" 

may be combined into one filter: 

Salary Group 

10000 EE 

One might now "or" compound constraints into this filter 
(by adding tuples) only if they are of exactly the same form 
as the first; the filter cannot be used for <salary> 
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constraints alone / nor for <group> constraints alone. Note 
also that a +Filter and a -Filter could not be combined in 
this manner. 

In a similar fashion, certain state word 
constraints may be added to a content/context filter, given 
that the RSM_eval uated_funct ions_ has been designated as the 
RSM for that filter. For example, if an existing filter for 
the <salary> field looked like 

Name Group 

Smith EE 

then we might specify that (in addition to passing <SmIth, 
EE>'s salary) anyone from EE could see his own salary by 
adding the tuple: 

<<user_id>, EE> 

where <user_id> is the flagged RN for the current user's 

name. 

This exhausts the methods by which different types 

of constraints may be combined wi th in a single filter. A 

pure content constraint could not be mixed in a filter with 

a pure state set constraint because the first requires a 

join with the Requested RDS, and the second requires a join 

with the state set. This is precisely the reason for the 

And_group construct of the ACL: for example, a compound 

constraint of the form 

if (<pure content constraint)) & (<pure state word 
constraint)) then..." 
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is represented by separate filters whose corresponding 
tuples in the ACL are connected via the And_group field. 
Any of the types of constraints may be "and"ed in an 
analogous fashion. The And_group may also be used to 
combine constraints which are representabl e in one filter, 
but this causes MARM more work. 

The highest level of logical "and'Mng is the 
<f ieldnumber> of the ACL_control RDS. This construct is 
provided primarily for MARM's convenience in computing ACL's 
for acquired RDS's, but could also be utilized by an 
originator of information who wished to share existing 
ACL's. 

In the interim system, the structure of the access 
control data base at and below the ACL_control RDS level 
will be largely under the control of the user who Is 
constructing it. It is clearly possible for him to 
represent his constraints in an extremely inefficient 
manner. To the extent that he wishes to specify simple 
restrictions, however, the complexity of the access control 
data can be minimized. 
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5.5. Standard Computat ion of Access Rights to Acaui red 
Rel at ion Sets 

It is claimed in Section k that the structure and 
philosophy of MADAM are such that the system must provide 
substantial aid in assigning access control data to derived 
sets. In fact, it should be possible to derive a set to 
which one has greater access privileges than he did to the 
input sets. 

The concept of filters and the MARM mechanisms 
presented in Section 5.4 provide the ability to determine 
whether or not a given RDS (and the current user's 
characteristics) satisfy the logical constraints specified 
by the ACL's. However, it is easy to demonstrate that the 
constructs presented there do not solve the problem of 
access control . 
5.5.1. What is Not Sufficient : The Problem of Truth 

The problem of Truth may be demonstrated by a 
slight variation of the example of Section 3. Suppose that 
there exist two system data sets: 

<Name/ Salary> 
and 

<Name, Group> 
both of which contain information about all people 
associated with Project Mac. Let the restriction on the 
<salary> field be the same as before, namely, that the 
current user is allowed P. access only to the salaries of 
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people also In Management. His access level to the two 

ex i st ing sets is M. 

There are (at least) two distinct ways that the 

user might derive a set containing only the salaries of 

Management people. He could create (by create_set and 

insert_tuple) either the set 

Name Group Salary 

* Management * (1) 

or the set 

Name Group 

* Management (2) 

Using set (1)/ he could acquire the desired result by the 
sequence of operations 

(<Name/ Group> join <Name/ Salary>) intersect (1) 

The join yields an intermediate set <Name / Group, Salary) 
which contains data on everyone from the original sets, so 
the user should not have JP access to it; the intersection 
yields the set of Management personnel only. 

Alternatively, the user might perform the sequence 
(<Name, Group> intersect (2)) join <Name, Salary) 

In this case, the intersection gives the intermediate set 
<Name, Group) of all Management people, and the join appends 
their salaries by matching on the <Name> field. 

Either of these actions produces a set to which 
the user should have P access. The +Filter which represents 
the sensitivity constraint on <salary> might look like 
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Group 
<group> 

where <group> is the flagged RN for the current user's 
gxpup. If our user is indeed in Management then this 
filter will pass the final acquired set. 

Suppose however, that the user performed this 
operation : 

<Name, Salary) join (2) 

The join would match on the <Name> field, which in set (2) 
contains a "*"; the result would be the set 

<Name, Salary, Group> (3) 

which lists al 1 the people from the original system data 
set, but in which the <group> field contains "Management" in 
every tuple. The filter shown above would pass this set as 
legit imate. 

This is the problem of Truth. Set (3) contains 
tuples which associate names with a group to which they do 
not belong. Although this is a simple example, the problem 
is not limited to the join operation; projection, 
composition, and product may also be used to alter the 
context of a sensitive field. Moreover, it is possible to 
completely remove the sensitive field in such a fashion that 
its contents are still known to anyone who knows the series 
of operations used to derive the final result. 



5. Interim Access Control System Page 72 

The example used here demonstrates that 
falsification may be performed in one step; it is easy to 
conceive of much more subtle ways to do so under other 
conditions of sensitivity. It is possible to construct 
cases where falsification occurs without the use of the "*" 
convention anywhere in the derivation history. 

To take a further example, suppose our user wishes 
to obtain the salary of the Provost, who is associated with 
the group "Admin", and who lives in Cambridge. In addition 
to the <Name, Salary> set and the <Name, Group> set, let the 
data base contain the following two sets: 

<Name, Town> 
(for everyone), and 

Group Town 



Management Cambridge 
Admin Cambridge 
(etc.) (etc.) 



where the last set contains the relation between groups and 
towns. Since people from different groups may live in the 
same town, some Data Elements may appear more than once in 
the <Town> field. In particular, at least one person from 
Management lives in Cambridge. If the user performs the 
following operation: 

(<Name, Town> join <Name, Salary>) join (<Town, Group>) 

then the final <Town, Name, Salary, Group> set will contain 
false information. The second join in the sequence matches 
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on the <Town> field, and will contain both the tuple 
<Cambridge, Provost, salary, Management> and the tuple 
<Cambridge, Provost, salary, Admin>, since Cambridge matches 
twice. The user could then intersect out the Management 
salaries from this (false) set, and obtain the Provost's 
salary. Clearly, identifying the point of falsification is 
not straightforward. 

The access control system must, therefore, know 
the derivation history of an acquired relation set in order 
to assign access rights, or it must know the Truth. It is 
not sufficient to have knowledge only of the state set 
variables and the content/context of the Requested RDS. 
Designing a system which knows the Truth is beyond the scope 
of the present work. 
5.5.2 Access Computation Rules 

Independent of the problem of Truth there are a 
number of cases in which access to an acquired set may be 
determined without resorting to the filtering technique of 
Section S.k. 

The only method by which one may increase access 
is by subsetting away that information which he is not 
allowed to see. In the example of Section 3, access 
increases from M to £ when the non-Management personnel are 
removed. If there are no context or content restrictions it 
is not possible to increase access in this fashion. The 
Restriction_flag in the KRDST indicates the presence of such 
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restrictions; if it is off, each field of the acquired RDS 
is assigned the minimum access level of the corresponding 
fields of the input. Thus if the only restriction is 
"Jones may not see salaries." 

then nothing Jones can do will allow him to increase his 
access rights to the <Salary> field. 

Moreover, the set operations union and product and 
the non-set primitive insert_tuple include all of the 
information of the input RDS's in the output RDS. The 
minimum access of the input fields is again assigned. 

In the case of intersection and difference it is 
not necessary to know the Truth. These operations are 
defined only for inputs which have the same RD's, and 

therefore no use of "*" or " " can produce false 

information in the output. Thus it is possible to increase 
access by subsetting if there are content/context 
restrictions on the inputs. In such cases, MARM evaluates 
the new ACL's of the acquired RDS in order to assign current 
access privileges. 

All of the remaining operations may falsify either 
content or context during the derivation of the acquired 
RDS. Even removing the sensitive field completely by 
projection is insufficient. If the <Name, Salary> set is 
intersected with 

Name Salary 

* 10000 
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and the <Salary> field of the result fs projected away, the 
user still knows the salaries of the remaining names. 
Therefore, the minimum access level of the inputs is 
assigned for replace_tuple, projection, join, and 
composition. Moreover, MARM cannot guarantee the accuracy 
of an RDS which has one of these operations anywhere in i ts 
der ivat ion h i storv . Thus the Fal se_content_f 1 ag and/or the 
Fal se_context_f lag are turned on In any RDS which is either 
derived directly from one of these operations, or which is 
derived from inputs which have the flags on. A set with 
either flag on not only prohibits increasing access, but 
also results in an acquired set which can never be used to 
increase access. 

This is the most severe shortcoming of the interim 
access control system; lack of knowledge about Truth places 
restrictions not only on the users of sensitive information, 
but also on the originators. In the example of Section 
5.5.1, the user could not acquire a set to which he has £ 
access from the given system data base -- the join operation 
must be used at some point to establish the (true) <Name, 
Group> relationship. It therefore does not make sense in 
the interim system to place context restrictions on 
sensitive information unless that context appears in the 
basic data set. Moreover the interim system wi 1 1 in some 
cases over-classify an acquired RDS; information which 
should be released will not be released. 
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In summary, the interim rules for assigning access 
privileges to an acquired RDS are: 

1) If there are no content/context restrictions 
on the inputs, or if the operation is anything other 
than intersection or difference, or if either of the 
inputs have the Fal se_content_f lag or 
Fal se_context_f lag on, then the access to each field is 
the minimum of the access levels to the input fields. 

2) Otherwise, evaluate the new ACL's to determine 
the access rights. 
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5.6. Non-Standard Access Hand! ing 

It is the aim of the access control system to 
support access control at a level sufficient to handle the 
needs of the great majority of users. However, the system 
is not closed; a user who wishes to have special 
restrictions on his data can do so. The only constraint 
which the interim system places on users is that assigned 
access privilege levels must be members of the set of 
capabilities of Section 5.2.1. 

Since the construction of the ACL's for an RDS is 
under the control of the originator of sensitive 
information, either he or anyone to whom he has granted the 
capability to change access information may place an 
arbitrary program (or programs) on the ACL. The 
<Access_handl er> field of the ACL will normally contain the 
name of a system-supplied program which tests constraints of 
the form described in Section 5.4. In these cases, the 
<Data_rds> field will point either to a filter RDS or to the 
State Set or Password Set. However, the access handler may 
be a user-supplied program. In this case, the <Data_rds> 
field of the tuple may, of course, point to any data in 
MADAM format. 

However, other users must be protected from the 
results of such programs. In the current Multics 
implementation a program called from a more privileged ring 
acquires the privileges of the caller; any program called 
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by f-'ARM will have f'ARM's privileges. It will therefore he 
necessary for a user who wishes to use his own access 
handlers to submit them for approval by system supervisors. 
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6. EVALUATION OF THE INTERIM ACCESS CONTROL SYSTEM 

This section summarizes both the good and bad 
points of the interim access control system. 
6.1. Generality and Compatibility 

Perhaps the most powerful feature of the interim 
system is its ability to represent access control 
information which is specified as a series of general 
logical constraints on the system state, the content of the 
sensitive field, and the context in which the sensitive 
information appears. The originator of Information Is no 
longer reduced to supplying an exhaustive list of the names 
of persons who can access his data; he can now make 
statements 1 Ike 

"Anyone can see his own salary." 

Through use of logical "and", "or", and "not", the 
originator may concisely specify complex conditions for the 
release of his information. 

This powerful representation of constraints Is 
supported by a very general definition of the term "user 
identification" — the state set supplies an extensive list 
of characteristics of the user which may be accessed for 
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many purposes. In addition/ the fine distinction of the 
term "access" greatly extends the types of access that may 
be assigned. 

Power is also provided by the separation of the 
concepts of the "owner" of information, the "originator" of 
information/ and the person (or persons) who may change the 
access control restrictions. It is possible to give someone 
a physical copy of sensitive information and allow him to 
manipulate it while denying him the ability to pass the 
information along to another user. 

The interim access control data base is compatible 
with the rest of MADAM data storage, with the exception of 
the <And_group> field of the ACL and the <fieldname> field 
of the ACL_control RDS, both of which require special 
handling. For the "pure" RDS's in the access control data 
base, all the MADAM operations are applicable; even in the 
case of these two impure sets, the non-set primitives 
provide powerful manipulative tools. Moreover/ the interim 
system uses only MADAM operators to make its access control 
decisions/ except for manipulations involving these two 
fields. 
6.2. Extensibil itv 

The interim system may be readily extended along 
both the second and third dimensions of access control. 

The division of "access capability" into P, M, 1/ 
N/ etc. is an arbitrary program restriction/ and might be 
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made either more or less coarse as experience dictates. The 
access handlers are completely independent of this division; 
a little cleverness in the programming of the MARM module 
itself will make such changes very easy to make. One 
conceivable extension, for example, would be an expansion of 
the C capability. In the interim system a user may change 
all of the access control information for an RPS, or he may 
change none. However, the access control data base itself 
is just a series of RDS's which are protected by exactly the 
same mechanisms as any other RDS; subdividing the C 
capability would amount to assigning their access rights 
individually rather than collectively. 

In addition, the use of the RSM for evaluated 
functions means that extension of the system to include more 
knowledge about the environment is a trivial matter -- since 
the state set is a pure RDS, and since the only interactions 
with it are through standard set operations, adding a field 
presents no problems. 

Lastly, the fact that the access handlers may 
themselves be arbitrary programs provides a convenient 
escape for special conditions, as well as a short-term 
solution to some of the limitations of the interim system. 

6.3. Limitations 

Clearly the most important limitation of the 
interim access control system is its inability to know the 
Truth. On this account, its performance in assigning access 
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privileges to new RDS's is severely impaired. All of the 
operations which may be used to falsify content or context 
may also be used in quite legitimate ways for obtaining 
information which the user should be allowed to see, but 
which the interim system will not release. 

The second limitation of the interim system is the 
complexity of the MADAM representation of access control 
restrictions in the ACL data bases. Expression of arbitrary 
n and n s, "or"s, and "not"s may well result in a large number 
of small RDS's which express the access control data for a 
single RDS. However, given the current configuration of 
MADAM, the representation presented here Is the simplest 
possible. 

A subproblem of the representation of logical 
constraints which further limits the access control system's 
operational power is the use of the <And_group> and 
<f ieldnumber> constructs, which make their respective RDS's 
impure and therefore not subject to manipulation by set 
primitives. This limitation, however, Is transparent to the 
user; it affects only the amount of special programming 
within MARM itself. 

From the user's viewpoint a more noticable 
limitation is the fact that only current MADAM operators may 
be used In expressing constraints; constraints involving 
arithmetic operators therefore presently require special 
purpose programming. This restriction applies throughout 
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MADAM, however, and is not limited to access control. 

The interim system's position along the dimension 
of physical level of control is relatively fixed: a 
decision to protect information at any level other than the 
field level within RDS's would be much more difficult to 
implement than a change in assignable access capabilities. 
However, such a change would affect only the MARM module 
itself. Moreover, the interim system allows one to protect 
specific fields of specific tuples; it is difficult to 
imagine an application for which this level of control would 
be insufficient. 

The last important limitation of the interim 
scheme is the fact that user-supplied access handlers must 
be submitted for approval before they may be used. This 
restriction results from the current Multlcs limitation that 
a procedure called from an inner ring has all the privileges 
of the calling program. Multlcs Is considering eliminating 
this restriction. 
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7. SUGGESTIONS FOR FURTHER STUDY 



This thesis has clearly identified at least as 
many problems as it has solved: 

First there is the problem of Truth. In a data 
management system which provides non-trivial mechanisms for 
manipulating information it is possible to construct false 
information in extremely subtle ways. This problem is by no 
means limited to the realm of access control -- it must be 
solved before MacAIMS can support a user interface which 
does more than map single commands into single set 
operations. Indeed / the problem affects users even if they 
specify set operations one-by-one; falsification might 
occur almost as easily by accident as by design. 

Second, there is the problem of interfacing 
general logical expressions with the existing MADAM 
structure. In the access control system, this is evidenced 
by the complexity of the data structure which results from 
forcing logical expressions into a data format which is ill 
suited for their representation. This problem also 
transcends access control. The addition of boolean 
operators to MADAM merits investigation in its own right. 

The need has also been shown for the addition of 
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arithmetic operators to the set of tools which MADAM 
supports. Such an addition is clearly desirable in 
providing power to the user. 

These issues all exist separately from the problem 
of access control , though their solutions would greatly 
enhance the access control system's capabilities. In 
addition there are two problems concerning access control 
alone which should be examined: 

First there is the question of results of 
computations which are final from the access control system 
viewpoint/ but which the user views as interim results for a 
computation which takes place outside the computer. The 
access control scheme cannot know if a user takes two 
printouts from different operations (or different login 
sessions) and intersects them in his head. The fact that 
access rights are assigned at each interim step in a 
computation provides a powerful tool for solving this 
problem/ but the responsibility for appropriate 
specification of constraints currently rests with the 
originator of sensitive information. A better understanding 
of the problem of partial results would help guide users in 
setting up their sensitivity specifications. 

Lastly, there is the problem of conflicts of 
privacy. The interim system provides for only one 
originator of information, along with the capabilities which 
"originator" implies; it would be fairly easy to extend 
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these concepts to include multiple originators of 
information who would have to collectively agree to its use 
cr dissemination. While such a simple idea would be a large 
step in the right direction, a much better theoretical 
understanding of conflicts of privacy is needed. 
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8. CONCLUSION 

This thesis has not been a dissertation on 
privacy; it presents the design of an access control 
subsystem for a particular data management system. The 
preceding pages not only demonstrate that no system in 
common use today provides a working environment in which 
users may conveniently protect the rights of others; they 
also show that furnishing that environment is not (and will 
not be) an easy task. The MacAIMS access control system is 
complex in structure; it will probably be costly to use. 
Moreover, it is not the whole solution to the access control 

probl em. 

But even establishing the environment is not 
enough. The MacAIMS interim access control system has no 
morals; it protects no one's privacy. We do not provide 
control; we provide the abi 1 ? tv to control. 

Data processing has no social value in its own 
right: it is a means to meet other ends. Yet the drive to 
collect data is extremely powerful in itself; left alone, 
it often becomes the goal rather than the means. The morals 
of privacy cannot be built into the hardware -- they must be 
built into the users, the programmers, the system 
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adm i n i s t ra to rs . 

Today our ability to collect, process, and 
disseminate information far outweighs our knowledge of what 
to collect, how to process it, and when to disseminate it. 
The time to close that gap must be now. 
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